【SORACOM Technology Camp 2018 レポート】「デバイス-クラウドの双方向通信デザインパターンと実践」#SORACOM

SORACOM Technology Camp 2018

#イベントレポート

#SORACOM

おおはしりきたけ

2018.11.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは！おおはしりきたけです。今日は、SORACOM Technology Camp 2018 に参加してきました。クラスメソッドでもIoTのプロジェクト増えてきており、本イベントでIoTシステム構築・運用の技術を学びたいと思いイベントに参加しました！

イベント概要

SORACOM Technology Camp 2018 のイベント概要は以下になります。

2019年に必要なIoTシステム構築・運用の技術を学ぶ1Day！

IoTが実践フェーズとなり、様々なシステムにセンサーや通信が取り入れられモノのデータが活用され始めています。「SORACOM Technology Camp」は、IoT に取り組む技術者・デベロッパーが、デバイス・通信・ソフトウェアなどの専門技術が密に連携するIoTシステムの構築・運用するために、最新技術や設計手法を学ぶラーニングイベントです。

第2回目の開催となる「SORACOM Technology Camp2018 」は、「IoT活用の実践」をテーマに、プロトタイピングや、IoTシステムの運用フェーズに必要な様々な仕組みを、SORACOMのサービスによる解決方法、ユースケースとライブデモを交えて解説します。 2018年7月に発表した新サービス「ダッシューボード作成・共有　SORACOM Lagoon」や、セキュアプロビジョニング「SORACOM Krypton」、「SORACOM LTE-M Button」を用いたプロトタイピングなど新しいセッションもお目見えします。

これからIoT に取り組む、もしくは来年度にむけIoTシステム提案を控えている技術者・デベロッパーの方は、ぜひご参加ください。

開催概要

開催日程	2018年11月22日（木）
開場と開始時間	開場：13:30 開始：19:30
参加費	参加費無料
会場	東京都品川区北品川5-5-15 大崎ブライトコア3F 大崎ブライトコアホール

タイムテーブル

時間	ベーシックトラック	アドバンストラック
13:30 - 13:50	開会宣言株式会社ソラコム執行役員プリンシパルソフトウェアエンジニア片山暁雄　/yaman	開会宣言株式会社ソラコム最高技術責任者安川健太　/kenta
13:50 - 14:35	事例で整理！IoTソリューションの開発/導入検討の進め方株式会社ソラコムソリューションアーキテクト今井雄太　/factory	モバイル回線で作るイントラネット　業務システムにもセキュアに連携株式会社ソラコムプリンシパルエンジニア松井基勝　/moto
14:50 - 15:35	そのデバイス、どうしたらIoT化できますか？事例に見るセンサー/デバイスのオンライン化デザインパターン株式会社ソラコムソリューションアーキテクト今井雄太　/factory	売れば売るほど大変"を防ぐ！「IoT デバイス初期設定の工数削減」手法株式会社ソラコムテクノロジー・エバンジェリスト松下享平　/max
15:50 - 17:00	今日から始めるセンサーデータの可視化株式会社ソラコムソリューションアーキテクト松本悠輔　/ysk	デバイス-クラウドの双方向通信デザインパターンと実践株式会社ソラコムソリューションアーキテクト須田桂伍　/kei
17:15 - 18:00	SORACOM LTE-M Button の始め方株式会社ソラコムプリンシパルエンジニア松井基勝　/moto	スモールスタートの次の一手は？成長できるIoTシステムの実例と回避したいポイント ― IoTシステム開発における試行錯誤の記録株式会社ソラコムテクノロジー・エバンジェリスト松下享平　/max

セッション

セッション概要

タイトル	デバイス-クラウドの双方向通信デザインパターンと実践
概要	IoTシステムではデバイスからクラウドへデータを送信するだけでなく、クラウドからデバイスの状態監視やデバイスへの制御命令といった、デバイスとクラウド間の双方向通信が必要となるシーンが多々あります。しかし、いざこうした双方向通信を実現しようとすると、様々な実装方式(どのアプリケーションプロトコルを利用する？メッセージキューは必要か？など)や考慮事項(リトライ、データ重複、データ到達保証など)が存在し、ユースケースにあった組み合わせや選択が難しいといった実情もございます。本セッションではデバイスとクラウド間の双方向通信を実現する際のシステムデザインパターンを整理し、どういった設計や実装のポイントが存在するのか、またその中でソラコムのサービスをどのように活用できるのかをデモも交えながらご紹介します。
登壇者	株式会社ソラコムソリューションアーキテクト須田桂伍　/kei

セッション資料

[slideshare id=123749964&doc=techcampadvanced3-181123013848]

セッションレポート

双方向通信が必要となるシーン

双方向通信は上り通信と下り通信
上り：温度情報、位置情報。動作ログ
下り：制御命令、遠隔監視、データ取得
双方向通信は観点が2つあり、サーバー主導かデバイス主導かでも異なる

代表的な双方向通信

遠隔制御：遠隔からデバイスに対して更新系の処理を実施
遠隔監視：遠隔からデバイスの状態や死活情報を取得/確認
M2M連携：デバイス間、デバイス - サーバーで自律的な連携を行う

双方向通信における考慮ポイント

本当にその通信必要ですか？まず検討したいこと
- 双方向通信は単純なデータ送信と比べ考慮することがとても多く実装も複雑になっている
- 要件そのもの、設計そのものを簡素にできないかをまずは検討することが重要
  - 通信要件自体
  - デバイス主導の通信として見直しできないか

考慮ポイント -　物理面

デバイス：どういったデバイスが対象か
電源：稼働時の電源確保
台数：対象とするデバイスの台数
制御内容：どういった制御命令を出すか？
セキュリティ：アクセス経路や制御情報は安全か？

消費電力と双方向通信

デバイスがバッテリー駆動の場合、待機時及び処理時の消費電力をいかに減らすかが重要
スリープ中は外からのリクエストを受け付けられないため、即時制御できない
双方向通信が求められるシーンでは消費電力と双方向通信の要件はトレードオフまたはそもそも相性が悪い

連携時に利用するプロトコル選択も重要

考慮ポイント -　アプリケーション

データ到達保証：データ到達をどこまで保証するのか？
リトライ：データ通信失敗時のリトライ戦略をどうするか？
順序制御：連携データの順序制御が必要か？
重複排除：連携データの重複削除が必要か？
冪等処理：連携処理は冪等になってるのか？

双方向通信とエラー処理の課題

IoTシステムでは多くの障害ポイントが存在
リトライ設計やデータ到達保証レベル設計は通常のシステム設計と同じくらい重要
特にデバイスへの制御を伴う双方向通信において
作り込み自体に制約があるケースも多い

双方向通信とエラー処理の解決策

ロジックはサーバーサイドへ配慮し、デバイスへ制御が到達する前に制御内容をハンドリングする
あえて同期通信/密結合な連携
リクエストを識別子処理済みリクエストを管理
制御自体を冪等な実装にする

デザインパターンの考え方

双方向通信は考慮ポイントも多く、実装をいくらでも複雑にできる
これまでの事例や経験をもとにデザインパターンという形で整理したのが本セッション
ユースケースや実現したい目的に応じて適切な方式案やソラコムのサービスを選択できるように整理

双方向通信の実現デザインパターンと実践

双方向通信デザインパターン

IPアクセスパターン
- IPを指定してデバイスへ直接アクセスする方式
アプリケーションパターン
- MQTTやLwM2Mなどの双方向通信を実現できるアプリケーションプロトコルを利用する方式
デバイスリードパターン
- デバイス側からの上り通信を利用する方式

プロトコル・スタックで見るパターン

IPアクセスパターン

特徴
- デバイスに付与されたIPを指定した通信
- 通常のサーバー間通信と同じ要領で処理できるので方式としてシンプル
課題
- いかにセキュアにエンドツーエンドをつなぐか

Gate利用時のパケット遷移

IPアクセスパターン実装時のポイント

ネットワーク設計
- 閉域接続先のネットワークアドレス重複などが無いようにアドレス設計は入念に
- Junction Redirectionを利用するとすべてのパケットがGatePeerを経由するので、インターネットへの出口も自社ネットワーク内に保つ必要がある
デバイス/アプリケーション設計
- IPでアクセスできる必要がある
- 常時リクエストにこたえられるようにしておくと相性が良い。そのため電源が常に確保できているシーンに向いている
- 一度に大量のデバイスを制御する際は場合によっては不向き

IPアクセスパターンまとめ

ソラコムサービスを組み合わせることで、最初からプライベートなネットワーク空間を利用可能
Canal/Door/Direct + Gate + JunctionによりIPベースでの双方向通信が可能
デバイスを指定した通信や、インタラクティブな制御に向いている
複数ネットワークを相互に接続する際はサーバー側のネットワーク設計も重要
ポートフォワーディングやエンドツーエンドでのVPNトンネリングも可能

アプリケーションパターン

特徴
- MQTT/LwM2Mといった双方向通信を実現できるアプリケーションプロトコルやSMSなどで利用
課題
- 作り込みによって複雑になってしまう

MQTT全般で気をつけたいこと

消費電力の観点で必ずしもMQTTが有利とは限らない
- ペイロードが大きいデータをやり取りしようとしてないか
- 通信量が想定以上に大きくなってないか

MQTTにしても勝手に省電力になるわけではない！

KeepAliveのための通信が発生するためバッテリー消費や通信量の増加につながるケースもある

SORACOM Inventory LwM2M

専用エージェントを通じて、デバイスの状態管理・設定更新・コマンド実行を可能にしている

OMA DM LwM2M

OMA DMとは？
- Open Mobile Alliance(OMA)で定められたデバイス管理の業界標準
- 通信プロトコルとデバイス管理オブジェクトを規定
OMA DM LwM2Mとは？
- OMAが定めたIoT/M2M向けのデバイス管理標準
- 制約のあるデバイスでも運用管理なプロトコルを採用している

Inventoryによる基本操作

デバイスへの命令はInventory APIにて実行する
デバイスへはLwM2Mによるリクエストが実行される
Observe/Notify
- 特定のリソースをObserveすることで、値の変更を起因にしてデータをサーバーサイドへプッシュ通知
- SORACOM InventoryではNotifyされたデータをSORACOM Beam/Funnel/Harvestへ連携可能

LwM2M利用時のポイント

LwM2Mで規定しているのはリソースIDとそれに対するリクエスト及びレスポンスのフォーマットであるため実際にどういった方法で値を返すのかはLwM2Mエージェントの内部実装次第
LwM2Mエージェントの起動やプロセス管理はOS側で設定が必要
定義済みリソースで要件を満たせないかを考える
必要なモデルのみを吟味すること